I am not sure what is the testing process if any, but let me know. Also I had no chance to try out the new bash path in any other systems than ubuntu and nix, so let me know if there is any problem with it in any other systems.

Great, what are the next steps?

(I also highly recommend trying out NixOs and nixpgs in general, pretty cool to do development on especially for command line)

im not sure that its necessary to pollute repo's root with files. can you create a directory structure like this?

(root)
|- packages
|--- nix
|----- default.nix
|----- ...

also is it really necessary to host this kind of thing on a main repo? don't packages usually have their own?

Typically the <root>/nix/ directory is used.

@uncenter It is possible with appending ?dir=nix in the url command, though I never seen it used, could you provide some well known examples? As far as I know this is not default behaviour.

@b1ek The nixpkgs can wrap your release with nix for sure, but it is not preferred (you need to have a maintainer updating versions and dependencies for this repo in a third party repo). This way it is also easy and unified to set up development env for Amber. (If you do not include it everybody on nix will have to write it himself, gitignore it before able to work on the project).

That's said these files are in root because they are just like .nmprc Dockerfile build.sh or project.toml. They contain packaging information. You can of course put these files in sub-folders and modify all your commands and paths to account for not being in the root even though it is not the default expected behavior.

@brumik does this installer build the Amber from scratch or does it use the latest release on GitHub? I'm trying to figure out how to solve it. By no means I've never used NixOS but by searching things on the web I've seen some people do some custom Bash in the installPhase of the flake config file. Let me know what if there is something I can help you with

It is not bash, but sh. Bash is not the default. You can of course run commands when building the package but in this case it is not needed. That's more of a case when you wrap an existing project and you need to do some more advanced manipulations with the compile targets.

It is hard to wrap your head around Nix but Nix is Source based and not Package based 'distro'. This means that the user compiles the program on their machine from a public repo URL. So in the example in readme it is using the main branch. But you can also specify a release branch or release tag or just a plain commit SHA.

As this project is not Nix fist project I would expect having Tags for each release that people on nix could reference.

(There are of course compiled binaries on a cache server for nixpkgs since you don't want to compile chrome and such on your machine, but that's catching detail and not how nix works in the first place.)

That's said these files are in root because they are just like .nmprc Dockerfile build.sh or project.toml.
...
Nix is Source based and not Package based 'distro'

The problem is, if everything gets thrown into repo's root it will make a horrible mess out of it. By "everything", i mean that Nix would not be the first distro to host package configs in the root of the repo.

I mean, just a few files is not a problem, but unspeakable horrors will unfold when 10 more distros or packaging systems like Nix will put their files in the root.

What about creating a separate repo only with config files and having github actions fetch the source & config files for each release/commit? That way, its easier to file issues and/or PRs about the package, the main repo is clean and nice and Nix packaging system is happy

There is no GitHub action that needs to be run. Flake.nix is telling NixOS what is needed to compile the code and how to compile it. So putting in new repo makes sense if the source code is in the new repo (aka a fork with one extra commit that needs to be synced)

We can probably remove default.nix and shell.nix since it is purely development purposes if we ship with flakes.

A example repo with super similar setup (CMD line tool written in rust) is https://github.com/jrmoulton/tmux-sessionizer

@brumik will this package require future maintenance or we can just leave this flake file and call it a day?

Does the installer recompile from source and update versions and tags on each install?

@brumik will this package require future maintenance or we can just leave this flake file and call it a day?

For the most part, no. Some rare cases where updating might be needed.

Does the installer recompile from source and update versions and tags on each install?

This flake instructs Nix how to build it from source, so yeah "recompile from source" is true but I'm not sure what you mean "update versions and tags on each install".

@uncenter I meant that it updates the Amber version automatically in the nix pkg registry when it detects that the Cargo.toml version changed. But I assume it does.

@uncenter I meant that it updates the Amber version automatically in the nix pkg registry when it detects that the Cargo.toml version changed. But I assume it does.

Currently there are two versions of the Amber package - one is upstream in https://github.com/NixOS/nixpkgs, which is auto-updated by a bot that detects when you release a new version (I am a maintainer for this package FYI), and the other is this new flake in this repository. This flake will always be fully up to date.

Hi, sorry to absolutely drop a massive review, but I worked with the team packaging this for upstream nixpkgs, and I would prefer it was done correctly here to. Thanks for doing this though.

@isabelroses It is much appreciated, great place to learn more.

@uncenter It is possible with appending ?dir=nix in the url command, though I never seen it used, could you provide some well known examples? As far as I know this is not default behaviour.

They did this with neovim before they moved the flake off the main repo ?dir=contrib though.

Thanks @isabelroses for your feedback!

I updated the PR and removed the default.nix and shell.nix files. @isabelroses and @b1ek could you give it one more look?

Yeah @brumik please move the installation details to NIX.md as it's a whole subsection that I'll add in the Documentation itself. Please mention it in the original README.md including the hyperlink to NIX.md. I think this PR is almost finalized and we'll be merging it.